Plugin Architecture

The following UML diagramms give you an overview about the packages and contained classes that were implemented to handle the different tasks the livetstatus interface has to handle:

• Initialize / Close connection to the MK_Livetstatus adress

• Define LQL queries to request data from livestatus  and send them via the network interface

• Receive replies and put them to Reply Objects

• Parse the reply objects and put the parsed data into a software model that represents the Nagios structure

• Offer the received data to the main plugin functinality

Overview about the packages and the classes they contain:

The Software model that represents the structure of the Nagios system (package "data"): 

The classes that control the program and select the parsing methods for the single Livestatus Replies (package "controller"): 

The network class to communicate with mk_livestatus (package "network"):

The request classes that implement the different kinds of possible livestatus requests. Each class contains the livestatus query language strings for the corresponding type of request (Host, Service, ...) (package "request"): 

The reply classes that store the reply strings which are received from livetstatus and are given to the parser  (package "reply"):

The parser classes to parse the reply that comes from mk_livestatus and puts it to the classes from the data package: